home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930112.txt < prev    next >
Internet Message Format  |  1994-06-04  |  5KB
  1. Date: Thu, 29 Apr 93 04:30:10 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #112
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Thu, 29 Apr 93       Volume 93 : Issue  112
  11.  
  12. Today's Topics:
  13.             Thoughts about alloc, bugs and RSPF. (3 msgs)
  14.  
  15. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  16. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  17. Problems you can't solve otherwise to brian@ucsd.edu.
  18.  
  19. Archives of past issues of the TCP-Group Digest are available
  20. (by FTP only) from UCSD.Edu in directory "mailarchives".
  21.  
  22. We trust that readers are intelligent enough to realize that all text
  23. herein consists of personal comments and does not represent the official
  24. policies or positions of any party.  Your mileage may vary.  So there.
  25. ----------------------------------------------------------------------
  26.  
  27. Date: Wed, 28 Apr 93 10:12:26 CDT
  28. From: andyw@aspen.cray.com (Andy Warner)
  29. Subject: Thoughts about alloc, bugs and RSPF.
  30. To: tcp-group@ucsd.edu (TCP Group)
  31.  
  32. Mike wrote:
  33. > [...]
  34. > The central problem of RSPF, about which there was an extensive series
  35. > of messages some months ago involving me, Fred Goldtein (goldstein@
  36. > carafe.tay2.enet.dec.com), and Anders Klemets (klemets@scis.se), is
  37. > that NOS provides no opportunity to test a route without using it.  It
  38. > is not desirable that routes which are in the process of being tested
  39. > by RSPF be used for anything else.  NOS provides no method by which to
  40. > [...]
  41.  
  42. An idea occured to me while reading this; would it be possible for
  43. RSPF function more as an autonomous process and source route any
  44. tests it used ? If it judges the route reliable, then it
  45. can update the routing table. I've not thought out any of the
  46. details so this probably woudn't work for many other reasons, but
  47. at least its a straightforward way of RSPF having "private" routes
  48. that its exploring.. I've never really understood why RSPF needs
  49. to know so much about low level stuff like ARP, but then again whenever
  50. I think about RSPF for too long my head hurts.....
  51.  
  52. -- 
  53. andyw. N0REN/G1XRL
  54.  
  55. andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
  56.  
  57. ------------------------------
  58.  
  59. Date: Wed, 28 Apr 93 10:12:26 CDT
  60. From: andyw@aspen.cray.com (Andy Warner)
  61. Subject: Thoughts about alloc, bugs and RSPF.
  62. To: tcp-group@ucsd.edu (TCP Group)
  63.  
  64. Mike wrote:
  65. > [...]
  66. > The central problem of RSPF, about which there was an extensive series
  67. > of messages some months ago involving me, Fred Goldtein (goldstein@
  68. > carafe.tay2.enet.dec.com), and Anders Klemets (klemets@scis.se), is
  69. > that NOS provides no opportunity to test a route without using it.  It
  70. > is not desirable that routes which are in the process of being tested
  71. > by RSPF be used for anything else.  NOS provides no method by which to
  72. > [...]
  73.  
  74. An idea occured to me while reading this; would it be possible for
  75. RSPF function more as an autonomous process and source route any
  76. tests it used ? If it judges the route reliable, then it
  77. can update the routing table. I've not thought out any of the
  78. details so this probably woudn't work for many other reasons, but
  79. at least its a straightforward way of RSPF having "private" routes
  80. that its exploring.. I've never really understood why RSPF needs
  81. to know so much about low level stuff like ARP, but then again whenever
  82. I think about RSPF for too long my head hurts.....
  83.  
  84. -- 
  85. andyw. N0REN/G1XRL
  86.  
  87. andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
  88.  
  89. ------------------------------
  90.  
  91. Date: Wed, 28 Apr 93 10:12:26 CDT
  92. From: andyw@aspen.cray.com (Andy Warner)
  93. Subject: Thoughts about alloc, bugs and RSPF.
  94. To: tcp-group@ucsd.edu (TCP Group)
  95.  
  96. Mike wrote:
  97. > [...]
  98. > The central problem of RSPF, about which there was an extensive series
  99. > of messages some months ago involving me, Fred Goldtein (goldstein@
  100. > carafe.tay2.enet.dec.com), and Anders Klemets (klemets@scis.se), is
  101. > that NOS provides no opportunity to test a route without using it.  It
  102. > is not desirable that routes which are in the process of being tested
  103. > by RSPF be used for anything else.  NOS provides no method by which to
  104. > [...]
  105.  
  106. An idea occured to me while reading this; would it be possible for
  107. RSPF function more as an autonomous process and source route any
  108. tests it used ? If it judges the route reliable, then it
  109. can update the routing table. I've not thought out any of the
  110. details so this probably woudn't work for many other reasons, but
  111. at least its a straightforward way of RSPF having "private" routes
  112. that its exploring.. I've never really understood why RSPF needs
  113. to know so much about low level stuff like ARP, but then again whenever
  114. I think about RSPF for too long my head hurts.....
  115.  
  116. -- 
  117. andyw. N0REN/G1XRL
  118.  
  119. andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
  120.  
  121. ------------------------------
  122.  
  123. End of TCP-Group Digest V93 #112
  124. ******************************
  125. ******************************
  126.